Documentation

# Permission Set Configuration

Defines role-based permissions and member assignments applied to sites, document libraries, and folders.

Referenced by: SiteCfg.PermissionSet, DocLibCfg.PermissionSet, FolderCfg.PermissionSet, Permission Set file handler.

# Overview

PermissionSetCfg defines a set of SharePoint roles (permission levels) and their members (users and groups). Permission sets are applied at the site, library, or folder level to control access.

Nested configurations:

  • PermissionRole (list) — individual roles with permissions and member assignments

# Applied when

Permission sets are applied when:

  • The parent SiteCfg is provisioned and references this permission set via PermissionSet
  • OR a DocLibCfg references this permission set via PermissionSet
  • OR a FolderCfg references this permission set via PermissionSet
  • OR the Permission Set file handler references this configuration
  • Applied during site, library, or folder provisioning; permissions are applied after the parent object is created
  • Retroactive permission changes can be enforced by setting ReAssignPermissions to true, which reapplies this permission set to all existing items/libraries that reference it
  • See Execution flow for how the properties interact

# Execution flow

The properties interact differently depending on the target object type.

# Non-root objects (sub-sites, libraries, lists, folders, documents)

These objects can inherit permissions from their parent. The steps below run in order:

1. ResetPermissions check

If ResetPermissions = true:

  • The object is reset to full inheritance (ResetRoleInheritance) — all unique role assignments are permanently removed.
  • If no Roles are configured → done. The object inherits from its parent.
  • If Roles are configured → continue to step 3 to apply them (inheritance will be broken at that point).

2. DisableInheritance / re-enable inheritance

If ResetPermissions did not run (or did run and there are roles to apply):

DisableInheritance Object currently inherits Object has unique permissions Action
true yes — Break inheritance. Copy parent roles if CopyRoleAssignments = true. Remove them if RemoveCurrentPermissions = true.
true — yes Nothing — already has unique permissions, no break needed.
false — yes Restore inheritance (ResetRoleInheritance). Done — no roles applied.
false yes — Nothing — already inherits.

3. RemoveCurrentPermissions

If RemoveCurrentPermissions = true: strip all existing role assignment bindings from the object before applying the new ones.

4. Apply Roles

Each entry in Roles (list) is applied: role definitions are created if missing, and members (DomainMembers, Groups, AzureAdSecurityGroups) are assigned.

# Root web (site collection root)

The root web cannot inherit permissions. The inheritance-related properties behave differently:

  • ResetPermissions and DisableInheritance do not call ResetRoleInheritance (no parent to inherit from).
  • CopyRoleAssignments has no effect.
  • ResetPermissions = true or RemoveCurrentPermissions = true: all existing role assignment bindings are stripped from every user and group on the root web before applying the new roles.

Flow:

  1. If ResetPermissions = true or RemoveCurrentPermissions = true → strip all existing role assignments.
  2. Apply configured Roles (list).

# Summary table

Property Non-root effect Root web effect
ResetPermissions = true Restore inheritance (wipe unique permissions), then apply roles Strip all role assignments, then apply roles
DisableInheritance = true Break inheritance from parent No effect (already unique)
CopyRoleAssignments = true Copy parent role assignments when breaking inheritance No effect
RemoveCurrentPermissions = true Strip existing role assignments before applying new ones Strip all role assignments before applying new ones
ReAssignPermissions = true Force re-apply even if config hash unchanged Force re-apply even if config hash unchanged

# Core settings

# Name

Type: string | Default: — | Required: Yes

Unique name. Referenced from sites, libraries, folders, and the Permission Set file handler.

# DisableInheritance

Type: bool | Default: false | Required: No

Break permission inheritance from the parent. AUTOMATIC: If any role has DomainMembers or Groups defined, this property is automatically forced to true regardless of the configured value. Permission inheritance is always disabled when role assignments exist.

# CopyRoleAssignments

Type: bool | Default: false | Required: No

Only applies when DisableInheritance is true. When breaking inheritance, copy parent role assignments first before applying configured permissions.

# ResetPermissions

Type: bool? | Default: null (off) | Required: No

⚠️ Destructive when enabled.

When true, all existing permissions on the target object are permanently wiped before the configured roles are applied. Any permissions set manually in SharePoint that are not in this configuration will be lost without warning.

The exact behavior differs by object type:

  • Sites, libraries, folders, list items: calls ResetRoleInheritance() — the object is reset to fully inherited permissions (all unique role assignments removed), then broken again and the configured roles are applied from scratch.
  • Site collection root web: cannot inherit, so instead all role assignment bindings are stripped from every user and group individually, then the configured roles are applied.

null / false (default): existing permissions are left in place and the configured roles are added on top.

# RemoveCurrentPermissions

Type: bool? | Default: — | Required: No

Remove all current permissions before setting new ones.

# ReAssignPermissions

Type: bool? | Default: — | Required: No

Only applies to existing objects (new objects always get the permission set applied). When enabled, reapply this permission set to existing items/libraries, even if the configuration hasn't changed. Useful when you need to enforce permission changes to already-provisioned items.

# Permission roles

# Roles

Type: PermissionRole (list) | Default: — | Required: No

Array of role definitions with name, permissions, and members.

# Role definition (within Roles (list))

# Name

Type: string | Default: — | Required: Yes

Role name. Can be built-in (Reader, Contributor, Full Control, Approver, Designer, Limited Access, View Only) or custom.

# Description

Type: string | Default: — | Required: No

Role description.

# Permissions

Type: PermissionKind (list) | Default: — | Required: No

Array of permission kinds. Examples: ViewListItems, EditListItems, DeleteListItems, OpenItems, ManagePermissions, etc.

# RoleType

Type: enum? | Default: — | Required: No

Built-in role type.

# DomainMembers

Type: string (list) | Default: — | Required: No

Array of domain user or group logins (e.g., user@contoso.com, contoso\groupname).

# Groups

Type: string (list) | Default: — | Required: No

Array of SharePoint group names (e.g., Matter Readers).

# AzureAdSecurityGroups

Type: string (list) | Default: — | Required: No

Array of Azure AD security group IDs or names.

# Matter list permissions

# MatterListFolderEnabled

Type: bool | Default: false | Required: No

Enable folder-level permissions on Matter list. When true, matter list items can be moved to folders specified in MatterListFolderName.

# MatterListFolderName

Type: string | Default: — | Required: No

Only applies when MatterListFolderEnabled is true. Existing folder name in the matter list where items will be moved. Leave empty to move to root.

# MatterListFolderPermissionsEnabled

Type: bool | Default: false | Required: No

Only applies when MatterListFolderEnabled is true. Apply configured permissions to new folders created in the matter list.

# MatterListItemPermissionsEnabled

Type: bool | Default: false | Required: No

Apply item-level permissions to matter list items. When true, enables individual permission assignments per matter list item. When false, inherited permissions are used.

# MissingUserGroupUpdatePropertyBag

Type: bool | Default: true | Required: No

Update the property bag even when referenced users or groups are not found. Set to false to skip property bag updates if any member resolution fails.

# Built-in roles (common)

Role Description
Reader View only access. OpenItems, ViewListItems, ViewVersions, ViewFormPages.
Contributor Can create and edit items. EditListItems, CreateListItems, OpenItems, DeleteListItems, ViewListItems, ViewVersions, ViewFormPages.
Full Control Complete administrative access. All permissions.
Approver Can approve items. Contributor + ApproveItems.
Designer Can design pages and templates. Contributor + design permissions.
Limited Access Minimal access (system role). Cannot grant manually.
Last Updated: 4/20/2026, 12:54:05 PM